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(54) System for adding attributes to an object at run time In an object oriented computer 
environment 



(57) The system uses an Intermediary process In an 
otiecX oriented computer environment to allow applica- 
tion objects to perform operations such as creation, 
deletion and accessing of other objects. Typically the 
other objects are database objects. The intermediary 
process allows associations to be made between add- 
on attributes and primary objects. The primary objects 



are objects that ere designed.to be used tv an original 
application. A later application that wishes to use the 
same obyects as the original application, but with addi- 
tional attributes, can create, delete and access tiie addi- 
tional attrbutes at run time so that extra functionality is 
provided to a user of the original application program in 
an efficient manner. 
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Descilptlon 

A portion of the disclosure of this patent documerit contains material which Is subject to oopyright protection. The 
copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disdo- 
s sure as it appears in the Patent and Trademark Office f De or records, but otherwise reserves all copyright rights what- 
soever. 

The invention relates generally to data processing in computer systems and specifically to adding attributes to 
objects in an object oriented environment executing in a computer system. 

Computer systems have seen widespread use in many fields ranging from financial, control systems, data process- 

10 tng and other apptications. Typically, a user of the computer system executes a program, called an application program, 
to perform a specific function or task such as word processing or coordinating the operation of an assembly line. TTie 
application program, almost without exception, operates on data that is a separate entity from the application program. 
The data has characteristics that are distinct from the application program. Unlike the applicatian program the data does 
not consist of executable instructions that direct the computer system to perform actions but Is, instead, a collection of 

15 information upon which the appGcation program performs functions. While the application program typically does not 
change during its lifetime, the data is constantiy being added to, modified and sometimes destroyed under the operation 
of an application program manipulating tiie data. 

A problem with tiiis approach is that it Is difficult to change the application program and data to work wHh data that 
requires additional information that wasnl contemplated in the initial version of the application program. This Is because 

20 data is inherentiy 'static' In its definition. In other words, data is rigidly defined so tiiat the application program knows 
invariable specifics about the data that the applk;ation program relies upon in manipulating the data. For example, 
where ttiere is a computerized record of information about employees ttiat is searched and updated by a personnel 
management program the personnel management program expects that If each record is defined to include a person's 
narne and telephone number then there is no provision for addng a second telephone number to the database. In this 

£5 example, the person's name arvJ telephone number are called fields" of the record. The number and order of fields In 
the record is referred to as the record's "data format" 

The reasons for having static, or fixed, fields Is that processing is faster because the application program knows 
exactly what each record contains and where to look for each f iekl. This Is analogous to having forms that make it easier 
for humans to search and retrieve specific types of inforniation. However, a problem with this approach is that it prevents 

30 modrftcation and Inprovementto the application program and data structura In order to provide tiie application program 
with the ability to manipulate additional fields, the application program must be modified to handle the new data struc- 
ture. This usually means that the original devekiper of the application program rrrust release a new version of the appli- 
cation program that the user must use to replace the prior applicatbn program. This means additional cost to the user 
to obtain and install the new application program. The reason that tiie developer must release a new version of tiie 

35 application program is that tiie properties of the record, for example the number and type of fields in the record, are 
ingrained into the application program by a process called "compilation." discussed below, tiiat forces a programmer of 
the application program to exacUy define the record. If tiie record format is changed, the entire application program 
must be recompiled with the new record definition. 

Potentially, an even bigger problem with modifying tiie record format is that all of the records in the old data format 

40 need to be translated into records in tiie new data format. This is similar to copying the information from an old form into 
a new form for each person in the database. Where there are many records, or forms, this translation task can be a 
huge one. Solutions such as maintaining two separate copies of each record, one in the original format arrd one in 
another format, are too burdensome in the amount of computer storage and cross-referenced updating tfiat must be 
performed. 

45 Another disadvantage of the traditional data processing model is that ct is very difficult for third party developers 
(i.e., a manufacturer other than the original manufachjrer) to add hjnctionalrty to the original application program. To 
continue with the exanple. if a third party wanted to come out with an add-on to the original application program that 
handled a second teleptione numt>er for each person in the datat^ase. It would be very difficult if not impossible, for the 
third party software to modify the datat)ase to Include tiie second telephone number and still leave the database com- 

so patit>le with the original application program ttiat had no provision for handling the second telephone number. 

Fig. 1A illustrates the steps and components to modify shared data definitions in the ti^itional data processing 
model. In Fig. 1 A, application program source code 102 is designed to process data types defined by data declaration 
104. Typically the steps of preparing the application program source code and data declarations are performed by a 
hurrran programmer. Next, application program source code 102 and data declarations 104 are provided to compiler 

55 106. Compiler 106 is software executed by a computer at "conpile time* that combines the infonnation in application 
program source code 102 and data declarations 104 along with, for example, language definitions, predefined library 
modules, etc. to produce executable 108. 

Executable 108 is loaded Into oorrputer system 1 1 0 to become loaded executatde image 1 14 whidi is executed at 
"run time" so that instructions defined by application program source code 102 are executed to perform the intended 
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functions. During the course of executing the instructions, data structures 1 16 are created, modified or deleted in mem- 
ory according to data declarations 104. Other software thai is part of the run^me environment, such as operating sys- 
tem software 112. also executes within the computer system. Data stmctures 1 16 may be swapped back and forth from 
a persistent storage mears such as storage 118. 

s From Rg. 1 A it should be apparent that, in order to modify data structures 116 within computer system 1 10, it is 
necessary to mocGfy data declarations 104. re-compile application source code 102 with the new data declarations, re- 
load the resulting executable and execute the new executable image. Since each application program that uses the data 
structures at run time must be compiled with the desired data declaration, the traditional data processing model of Rg. 
1 A makes it very difficult to achieve the goal of efficient addition of functionality by a third party. 

10 One effort at solving the problems of the traditional data processing model described above is with the so-called 
"object oriented" approach to programming. The object oriented approach is successful in providing a standard so that 
added functionality can be developed independently by third party developers and still be compatible with original func- 
tionality developed by an original developer. The object oriented approach also defines a way to manipulate data that 
allows more f lexltsility over the traditional data processing model. However, the object oriented approach does not fully 

IS solve the problems described above. 

This specification discusses the invention with specific regard to two exemplary Implementations of object oriented 
approaches. Namely, the C++ language environment and the Object Linking and Embedding (OLE) operating system 
environment by Microsoft Corp. A detailed description of the C++ object oriented environment may be found, for exam- 
ple, in Borland C++ User's Guide and Borland C++ Ubrary Reference manuals and other information provided by Bor- 

20 land. Inc. about their C++ language implementation. Microsoft Press publishes "Inside OLE 2,' 1st and 2nd editions, by 
Kraig Brockschmidt which describes OLE in detail. A large number of texttxioks on the sutjject of object oriented pro- 
gramming, in genera), are available. For example, "Object-Oriented Analysis and Design." by James Martin and James 
J. Odell, Prerrtice Hall, may be consulted for principles of object oriented design that are not specific to a particular 
implementation of an object oriented environment such as C++ or OLE. 

25 A minimum of the concepts and details of object oriented environments is discussed in this specification for pur- 
poses of disclosing the invention and distinguishing the invention over the prior art Where this specification uses terms 
in contrary manner to the available literature, this specification is controlling. Note that the available literature, itself, 
sometimes provides jargon with conflicting definitions for the same terms. 

The object oriented approach centers around the idea of an "object." An object can Include executable Instructions 

30 and/or data. This is unlike the traditiona) data processing nvxlel discussed above where the database did not include 
executable instructions. Instead the executable instructions in the traditional data processing model were part of the 
application program, only. An advantage to iising objects is that the database can now include sets of instructions, often 
called "methods," that perform functions on the data. Thus, the original application (which would also be an abject) in 
the object oriented world might pass telephone number data to the database object and request that the telephone 

35 number be stored in the database. The database would then store the telephone number in the database in the proper 
field. 

A third party application could be designed to handle a second telephone number. This third party application, or 
"derivative" application, would produce data files that are incompatible with the data files of the original application. The 
derivative program would be able to read data produced by the original program but the derivative program would not 
40 be able to write the second telephone number to data files created by tiie original program. The original program would 
not be able to read data files produced by the derivative program. 

Thus, the object oriented approach does not fully solve the problem of allowing truly independent development of 
additional hjndionality where the added functionality requires a change in the data format Typically, data translation 
from the original data format to the derivative data format would have to be performed by the user. This necessarily 
4S requires that the derivative program developer understands the original application developer's methods for handling 
thef irst telephone number. Similariy, the original developer cannot update its system and include an update of the data- 
base object without adversely affecting the user's system when the user's system includes the third party datat>ase 
object unless the original developer incorporates the third party developer's methods for handing the second telephone 
number. Thus, the prior art problem of efficientiy adding independent third party functionality still exists in the object ori- 
50 ented data processing model. 

The object oriented data processing model is limited in the same way that the traditional data processing model is 
limited in that the format of data types manipulated by different applications must be defined in advance of executing 
the application programs to manipulate the data. 

Rg. IB illustrates the steps and components to modify a database object in the object oriented data processing 
55 model. The datat)ase object is used by different application programs at run time so that a single database object may 
be common to two or more application programs. 

Similar to the step of creating application source code and data declarations in Rg. 1 A, database object definition 
130 is created by a human programmer as the first step in Fig. IB. Next database object definition 130 is provided to 
compiler 132 which perfonms sinrrilarly to the conpiler of Rg. 1 A and generates executable object 134. 
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Executable object 134 is loaded into computer system 136. Executable object 134 is shown within computer sys- 
tem 136 as database object 1 38. Database object 138 is executed at run time In the object oriented environment that 
includes application object 1 , application object 2 and various environment ot^ects 140. Environment objects 140 may 
include, for example, standard ot^ects in an environment such as OLE. During the course of execution, the application 
5 objects access database object 138 so that a database according to datat>ase object definition 130 may be aeated, 
modified and deleted. Portions of the database may be moved from memory 142 to persistent storage 144. 

Note that even though the object oriented data processing model of Fig. IB provides advantages over the tradi- 
tional data processing model of Fig. 1 A, there are still drawbacks. One problem is that, in order to change the database 
definitions it is still necessary to modify database object definition 1 30 and perform the compile, load and execute steps. 
10 Thus, in the prior art, adding properties, or "attributes." to an existing object is difficult. This specification refers to the 
modification of an object so that additional functionality (in the form of an additional method) or additional information 
(in the form of additional data) is associated with the object as adding an 'attrbute' to the object. 

In C++, attributes can be added to existing objects by 'dass inheritance," or "sutsdassing," from existing object 
classes. In OLE. attributes can l>e added to existing objects by "aggregating" an existing object class. Essentially, both 
15 ways of adding attributes to existing objects create a new object dass tiiat incorporates the data types Of the existing 
object and adds data types. 

As a further example of the prior art, aggregation in the OLE environment is next cfiscussed. 

OLE provides a data model called the Component Ot^ect Model (COM). COM allows objects to have data, in tiie 
form of "properties." and executable functions, in tiie fomn of "methods." Ateo. objects have "interfaces" so that other 
20 objects can invoke and make use of a given object's functionality (i.e.. 'attributes," including properties and methods) 
by making "requests" to the given object through the interfsces. 

Fig. 1 C is a diagram of a COM object 200. COM object 200 has a name. "Object_A." ObjecLA indudes interfaces 
202, 204 and 206. Object_A also indudes attributes such as executable functions 210 and 212. and data 214 and 216. 
Object_A also indudes a sep£UHte object named Object.B. Note that Object_B indudes its own executable functions 
25 220 and 222 along witti data 224 that is internal to Object_B. Object_B also indudes interface 230 that is only directiy 
accessible to Object_A and interface 206 tiiat is "directiy exposed' through Object_A to the object-oriented environ- 
ment so that other objects may access Object_B directiy tiirough interface 206 even though interface 206 appears to 
be an interface of Object_A 

The mettiod of directiy providing an included objecTs interface (206 in Fig. 1C) through tiie induding object 
30 (Object_A in Rg. 1C) is known as "aggregation" in OLE. This allows attributes to be added to an existing object, 
Ob)ect_A. However, tiie specifying of aggregated objects must be performed at compilation time so this approach has 
the same drawbacks £is the other prk^r art approaches discussed abova Further, tiiere are problems with handling the 
interfaces in aggregated objects that require additional memory overhead to maintain pointers and otiier referential data 
t>etween the aggregated objects. 
35 It is the objed of the invention to provide an innprovedmettiod for assodating a property vtrH 
ter system that effiderrtiy allows attributes to be added to existing objects at runtime. 
This object is achieved with a method having tiie features of claim 1. 

The present invention allows attributes to be assodated witii objects at run time. In one embodiment this is acoonfv 
plished by providing additional code for associating, or registering, interfaces to existing objects, deleting interfaces 

40 from existing objects and determining which interfaces are assodated with an ot)iect. 

The invention indudes a metiiod for associating a property witii an object in a computer system. The conputer sysr 
tern indudes a processor coupled to a memory and a storage device. The computer system also indudes objects hav- 
ing data members and dass definitions speaking one or more dass properties of an object The method indudes the 
steps of compiling a definition of a first object as a first instance of the dass, wherein the first object lias the dass prop- 

45 erties specified in the dass: compiling a definition of a second object as a second instance of tiie class, wherein the 
second object has the dass properties specified in the dass; and compiling a definition of a tiiird object, wherein tiie 
third Gbject includes an added property that is not specified in tiie class. 

Further, in the method, tiie following steps are performed subsequent to the ^eps at}0ve: using tiie definition of a 
first object to create a first object; using ttie definition of a second object to aeate a second object; using the definition 

so of a third object to create a third object; associating ttie third object witii the second object; executing instructions in a 
first application to access ttie first object and transfer Information about the first object's dass properties to tiie first 
application; executing instmctions in the first application to access ttie second object and transfer information about tiie 
second object's dass properties to the first application; and executing instructions in a second application to access the 
second object and transfer information about the added property of ttie third object assodated with the second object 

55 to the second application. 

The invention will subsequentiy be descrbed in more detail by way of exanrple v«tti reference to ttie appended 
drawings. 

Fig. 1A illusbBtes ttie steps and components to modify shared data definitions in a traditional data processing 
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. model; 

Fig. 1 B illustrates the steps and oomponents to modify a datat>ase object in ttie object oriented data processing 
model; 

Fig. 1C is a diagram of a COM object; 
5 Rg. 2 is an illustration of a computer system suitable for use with the present invention; 
Rg. 3 is an illustration of basic subsystems in the computer system of Fig. 2; 
Rg. 4 illustrates the concept of eatelite data underlying the present invention; 

Rg. 5 illustrates an embodiment of the present invention providing a persistence si^ystem for maintaining asso- 
ciations between original database objects and attribute objects; and 
10 Rg. 6 shows a flowchart of the steps in the operation of the embodiment with the persistence subsystem of Fig. 5. 

Rg. 2 is an illustration of a computer system suitable for use with the present invention. Rg. 2 depicts but one exam- 
ple of many possible conputer types or configurations capable of being used with the present invention. Rg. 2 shows 
computer system 1 including display device 3, display screen 5, cabinet 7, keyboard 9 and mouse 1 1 . Mouse 1 1 and 
15 keytmrd 9 are "user input devices." Other exarrples of user input devices are a touch screen, light pen, track ball, data 
glove, etc. 

Mouse 1 1 may have one or more buttons such as buttons 13. Cabinet 7 houses familiar computer components 
such as disk drives, a processor, storage means, etc. As used in this specification 'storage means" includes any stor- 
age device used in connection with a computer system such as disk drives, magnetic tape, solid state memory, bibble 
20 memory, etc. Cabinet 7 may include additional hardware such as input^output (I/O) interface cards for connecting com- 
puter system 1 to externa) devices such as an optical character reader, external storage devices, other computers or 
additional devices. 

Rg. 3 is an illustration of basic subsystems In computer system 1 of Rg. 2. In Fig. 3, subsystems are represented 
by blocks such as central processor 52, system memory 54, display adapter 55, monitor 57, etc. The subsystems are 

25 interconnected via a system bus 50. Additional subsystems such as a printer, keytx>ard, fixed disk and others are 
shown. Peripherals and irput/oulput (I/O) devices can be connected to the computer system by, for example, serial port 
58. For example, serial port 58 can be used to connect the computer system to a modem or mouse input device. The 
irrterconnection via system bus 50 allows central processa 52 to communicate with each subsystem and to control the 
execution of instructions from system memory 54 or fixed disk 60, and the exchange of infomiatton between subsys- 

30 terns. Other arrangements of subsystems and Interconnections are possible. 

The present invention provides advantages to application programs executing in c^ocX oriented environments such 
as OLE. In OLE, COM objects are described by the interfaces that they support Each interface is a means to access 
data or invoke a function of the object. Thus, an objects attrbutes (i e., data or functions) are determined by the number 
and type of interfaces tfiat are provided to the object. In order to add attributes to existing objects, the present invention 

35 uses a program that creates, destroys and otherwise maintains and provides information on attribute assodatians 
among objects, attributes and interfaces at run time. In an embodiment currently under development, this invention is 
being adapted for use in an application known as Viking. The program that maintains the attribute associations Is called 
the Persistence Subsystem and the attribute associations are referred to as "satellite data." 

Rrst some of the advantages of using satellite data in application programs are presented. Next, the manner in 

40 which the Persistence Subsystem implements satellite data is discussed. Finally, the differences between satellite data 
and standard object oriented approaches to adding attributes are described. 

An example of an application that uses satellite data is a software architectural package that allows a user to model 
the interior layouts of rooms in a buikiing. The package supplies database objects that describe the geometry of the var- 
ious types of furniture that can be placed in a room, and application objects for making room layouts using the furniture 

4S desaibed by the database objects and displaying the results. The furniture shapes are stored In the database objects 
as geometric shapes with a uniform surface. Sometime after the original software pad^ge has been delivered, the orig- 
inal developer, or another developer, can provide an add-on applicatton object that gives the capability to descraae the 
surface material of each of the objectK. Thus, the furniture can now have more detail since cotors or textures can be 
rendered when the furniture is displayed to give more realistic images. 

so Rg. 4 illustrates the concept of satellite data in the software architectural package described above. In Rg. 4, data- 
base 200 includes database ot]jects 202-21 2. Database objects 202-21 2 are created, accessed and destroyed by orig- 
inal application objects 214. Satellite data in the form of added attribute objects such as attributes 216-220 is also 
shown in Fig. 4. In Rg. 4, the association of an added attribute with a database object is shown by having the added 
attrbute object adjacent to the associated database object Thus, attrbute 21 6 is associated with database otiject 202, 

55 attribute 2 1 8 is associated with database object 2 1 0 and attribute 220 is associated with datat)ase object 21 2. 

In accordance with the example, original application objects 214 implement the original software architectural pack- 
age with the sinple furniture shape representation (i e-. without surface material). Original application ofcyects access 
the database objects via the database objects' interfaces as suggested by lines from original application ot^ects 214 to 
representative database objects 202. 206 and 208. The database objects are accessed, for example, to provide data 
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or perform functions, such as obtaining the dimensions of a piece of furniture being modeled by the database object or 
to have the database ot^ect display a piece of furniture. 

On the other hand, add-on application objects 222 are provided to create, access and destroy the added attribute 
objects. In the example, the added attribute objects include information for displaying a pieoe of furniture in a database 
s object with surface material. The add-on application objects allow a user to create the added attribute by specifying a 
surface materia), assign the attribute to one or more database dbjects, and further edit or destroy the added attribute 
objects. Note that the original application objects will never access the added attribute objects since the original appli- 
cation objects were designed prior to, and independently of, the added attrbute objects and do not have any knowledge 
of the added attribute objects. 

10 On the other hand, the 8x36-on application may have knowledge of the original database objects and may access 
their interfaces. This allows the add-on application to easily add functionality to the existing software architectural pack- 
age. For example, where the original package has a 'draw" command for invoking the drawing function In a database 
object to draw a piece of furniture as a flat-shaded object, the add-on ot^ects include a "draw" command that accesses 
the datatKise object interface to draw the furniture as a flat-shaded object artd then accesses the associated attribute 

15 object's interface to render the furniture with a surface material. 

Table I shows a C function, DrawFumiture, that would be included in an add-on application to render a furniture 
object. FurnitureObject. differently depending on whether or not the fumiture object has surface materia) satellite data 
associated with it. Thus, the routine DrawFumiture con-esponds to the latter example where the add-on application has 
knowledge of the original datat>ase object format. 

20 

DrawFurniture ( FurnitureOb j ect *pObject ) 
{ 

struct surf aceHaterial Material; 

if ( DoesSatelliteDataExistC pObject, SURFACE__MA.TERIAL )) 
{ 

GetSatelliteData ( pObject, SURFACE_MATERIAL, 

&Mat:erial }; 

RenderObj ectff ithSurf aceHaterial ( pObject, Material 

} 

else 
{ 

StandardRenderOb j ect ( pObject ) ; 

} 



TABLE I 

40 



Two functions are used to extract the satellite data. A first function, DoesSatelliteDataExist, returns TRUE or 
FALSE, depending on whether or not the requested type of data has been associated with the object in question. A seo- 

45 ond function, GetSatelliteData. actually retrieves that data. In the example of Table I, the satellite data described in 
structure SuitaceMaterial is identified by the SURFACE_MATERIAL tag. 

Two additional functions, RenderObjectWithSurfaceMaterial and Standard RenderObject are used to draw the 
object on the screen with surface material or witfiout surface material. In the code example of Table I, RenderObject- 
WrthSurfaceMaterial is used to access both the satellite data describing a surface material, such as attribute 216 of Rg. 

so 4, and a standard database objea, such as database object 202. TTie function StandardRenderObject is used to render 
the otpject without satellite data by merely using the standard database ot^yect 202. 

There may be many more database objects in the datat>ase than the six shown in Fig. 4. Also, a database object 
may have more than one attribute assodated with it. Attributes may also t^e assodated with more than one database 
object This scheme allows a hierarcfiy of "layers" of attributes from many add-on application dbjects to be used with 

55 the original software package and original datatiase cd)jects. For example, attributes can be assodated with other 
attnlxjles. A given type of attribute, such as surface nBteria) data can b>e assodated with many different types of 
objects such as the database object to define furniture geometry and another database object that defines wiring or 
plumbing. An attribute object can be created to work with any database obged or the attribute object can be limited to 
certain types of objects. Broadly, the inv^on provides that attribute objects can be assodated with predefined objects. 



30 
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Note that the predefined objects, e.g., the database objects of Fig. 4, are typically created in the standard way by 
defining the database objects and then compiling the database object definitions as discussed above in connection with 
Fig. 1B. On the other hand, attribute objects such as attribute 216 may be d^tned in a similar manner and associated 
at "run time." 'Run time" is defined as the time at which the interfaces of the database objects and attribute ot^ects may 

s be accessed by application objects. The run time operation of the present invention is dscussed below in connection 
with the Persistence Subsystem. The preferred ennbodiment uses the Typelib, a data descrSiing component of OLE 
Automation, to define add-on objects. This allows the end-user to define and manipulate the attributes. Details of 
Typelib may be found in 'OLE 2 programmer^ Reference Manual,* published by Microsoft Press. 

This approach allows for true 'plug^nd-play" add-on applicatton objects. Any number of add-on application objects 

to can simply be assembled into application otijects on tfte fly. Even the end-user can assemble new objects by specifying 
that attributes be associated with existing objects. The attributes, themselves, can be defined by the user. For example, 
a user interface can allow a user to augment an existing object by picking an attribute represented as an icon from a 
palette, dragging the icon to a graphical representation of the existing abject and "dropping" the attribute on the existing 
otiject. By using the approach of satellite data there is no need to change object definitions for re-oompila The book- 

15 keeping overhead maintained by OLE and "C," such as the TypeLSi in OLE, is also used for attritiute definitions in the 
preferred embodiment. 

Fig. 5 illustrates the persistence subsystem's role in maintaining associations between original datat>ase objects 
and attribute objects. In Fig. 5. original application objects 302 and add^n application objects 304 may access, create 
and destroy datat>ase objects and attributes as befora however, all accesses, creation and deshuction operations are 

20 through a process refen'ed to in a preferred emtxxliment as the "persistence subsystem' 306. The persistence sibsys- 
tem maintains the association between database objects and attributes. The persistence subsystem may be imple- 
mented using additional objects, functions, procedures, etc. and may be an application program, part of the operating 
system or some other form of utility or resource within a computer system implements the present invention. In Rg. 5. 
'' persistence subsystem 306 is an object with an interface that is accessed by application otijects 302 and 304. 

2s In Fig. 5. persistence subsystem 306 is shown maintaining associations between datat>ase objects A-D and 
attrbutes 1 -4 by means of list 308 that irKludes object identifiers. In table 308. a primary object is shown for each row 
in the table as indicated by a letter. Any attributes associated with the primary object are shown In the same row as the 
primary object and are indicated with a number. To continue with the example above, the primary objects are tiie origi- 
nal application objects that specify simple geometries for furniture while the attributes are add-on satellite objects which 

30 include the surface material definition for their associated object. In the preferred embodiment a component called the 
Associativity System is used to nriaintain associations, or relationships. As will be readily apparent to one of skill in the 
art, many data structures or alternative ways to maintain associations between database objects and attrbutes are pos- 
sible. For example, data structures such as objects, tatstes of pointers, etc. may be employed. 

As shown in Fig. 5, persistence subsystem 306 acts as an intermediary for all operations by application objects 302 

35 I and 304 upon the database objects and associated attributes. This allows original application objects 302 to access 
original database objects A-D normally. This also alkMrs add-on applkation objects 304 to access attributes 1-4 which 
are associated with the database objects. For exanple, original application objects 302 can request chat data from 
database object A be obtained. Persistence sutjsystem 306 receives tiie request and accesses database object A for 
the requested data which is returned to the requesting object. When an add-on application object requests an attrbute 

40 value associated, e.g., witii database object B, persistence subsystem 306 detenmines that attribute object 1 is associ- 
ated with datatxise object B and requests the value from attribute object 1 . The value is then given to the requesting 
add-on application object. 

Note that the original application objects may still access database object B normally, even though database object 
B has additional data, in the form of attribute 1 . associated with it Both the original application ot^ects and tiie add-on 
46 applk;ation objects are free to access, create arxj destroy objects. The original application objects can create and 
destroy datet}ase objects while the add-on application objects can create and destroy both database objects and 
attrbutes. 

In the preferred embodiment, when a database object is destroyed, any attributes that are only associated with the 
destroyed database object and no other datat)ase object are, tiiemselves, destroyed. Anottier possibility is to keep tiie 

50 "orphaned" attribute objects in existence for later association with different database objects, or even allow accessing 
of orphaned attributes in the absence of any primary database abject associated with tiie attrbute. 

As shown in table 308, database objects may have zero, one or more attributes associated with thenn. Also, 
attributes may be associated with more than one database object Many variations on the type of assodatbns that can 
be made fctetween add-on attributes and primary objects are possibla As discussed atKve, there may be many layers 

55 of associations by having attributes associated with attributes. Also, primary objects can be associated with each other, 
as desired. The invention allows an intermediary process, such as the persistence sii)system in the preferred emtxxi- 
iment to aeate. maintain and destroy any logical associations between emy objects in the system. The actions of tiie 
intermediary process can be by the request of application, or other, objects, as in tiie preferred embodiment or may be 
by request of a user of the computer system, tiie operating system, the persistence subsystem, itself, etc. 
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Fig. 6 shows a flowchart of the steps in the operation of the persistence subsystem of Rg. 5 with respect to creat- 
ing, deleting and accessing an ot)ject In genera), the flowcharts in this specification illustrate one or more software rou- 
tines executing in a oonputer system such as computer system 1 of Rg. 2. The routines may be implemented by any 
means as is known in the art. For example, any number of computer programming languages, such as "C", Pascal, 

5 FORTRAN, assembly language, etc., may be used. Further, various programming approaches such as procedural, 
object oriented or artificial intelligence techn'ques may be enployed. 

The steps of the flowcharts may be iirplemented by one or more software routines, processes, subroutines, mod- 
ules, etc. It will be apparent that each flowcheul is illustrative of merely the broad logical flow of the method of the 
present invention and that steps may be added \xx or taken away from, the flowcharts wtttwut departing from the spirit 

10 of the invention. Further, the order of execution of steps in the flowcharts may be changed without departing from the 
core of the invention. Additional considerations in implementing the method described by the flowchart in software may 
dictate changes in the selection and order of steps. Some oonsiderations are event handling by intenupt driven, polled, 
or other schemes. A multiprocessing or multitasking environment oould allow steps to be executed 'concurrently." For 
ease of discussion the irrplementation of each flowchart is referred to as if it is implemented in a single "routine". 

15 In Rg. 6. flowchart 350 is entered at step 352 where it is assumed that an application abject desires to perform a 
creation, deletion or access operation on a primary cdiject or an add-on attribute of a primary object. At step 354 a check 
is made as to whether the desired operation is to create an object. If so^ step 356 is executed to determine whether the 
object to aeate is a primary abject or an attribute. If the object to be created is a primary object step 358 is performed 
to create the primary object and the routine exits at step 386. In OLE. this is performed in the standard way by using 

20 the OLE/COM function "CoCreate Instance." 

If. instead, at step 356 the object to be created is an add-on attribute, or satellite object, step 360 is performed to 
create the attribute. Next, step 362 is executed to update the table of associations to add an entry indicating that the 
attribute is associated with a specified primary object The routine exits at step 386. It is assumed that the calling object 
that wishes to create the attribute object also, specifies the primary object that is to be associated with the attribute 

25 object 

If, at step 354, the check determines that the operation desired is not to aeate an ot^ect, execution proceeds to 
step 364 where a check is made as to whether the desired operation is to delete an object. If so, step 366 is performed 
where a check is made as to whether the object to delete is a primary object. If not the object is an attribute object and 
step 368 is performed to delete the attrbute object The routine then exits at step 386. If, at step 366. the object to delete 

30 is determined to be a primary Object step 370 is performed to delete the primary object Next, step 372 is executed to 
delete any attributes associated with the deleted primary ok^ect. This is to prevent orphaned object as discussed above. 
Also, the primary objects row entry is removed from the table. The routine then terminates at step 386. 

If, at step 364, it is determined that deletion of an object is not desired, step 378 is executed to determine whether 
the requesting object wants to access an object or attribute in the database. If not. execution of the routine of fkwchart 

35 350 terminates at step 386. If so, step 380 is performed to deterntine whether the object to be accessed is a primary 
object If the ot^ect is a primary object then step 382 is invoked to obtain the desired value from the primary object. Note 
that accessing the object could be for purposes of invoking a function or method of the abject. In this case the persist- 
ence subsystem would invoke the corresponding function or method in the desired object. If the object is not a primary 
object then it is assumed that the object must be an attribute object and step 384 is performed to obtain the desired 

40 value from the object Any data manipulation of the object, invoking of executable code of the object, etc. can be per- 
formed at steps 382 and 384, similar to that allowed upon objects in an operating environment such as OLE or Oh-. 
After completion of either of steps 382 or 384 the routine exits at step 386. 

There are many object oriented environments produced by various developers and defined in many publications. 
Specific implementations or definitions of object oriented environments may differ, sometimes greatly, in the implemen- 

45 tation of standard concepts and principles of object oriented programming. However, it will be readily apparent to one 
of ordinary skill in the art that, although only two instances of object oriented environments, C+-i- and OLE are discussed 
in this specification, the invention may be applicable to any object oriented environment implementation as deterrrtined 
tjy the appended claims. 

so Claims 

1 . A method for associating a property with an object in a computer system, wherein the conputer system includes a 
processor coupled to a memory and a storage device, wherein the computer system includes ot^ects, wherein an 
object includes one or more data memt>ers, wherein the computer system includes a definition of a dass that spec- 
55 ifies one or more class properties of an object, the mettiod oonprising the steps of: 

compiling a definition of a first object as a first instance of the dass, wherein the first otiject has the dass prop- 
erties specified in the class; 

compiling a definition of a secorvJ object as a second instance of the class, wherein tiie second object has tiie 
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dass properties specified in the dass; 

oompDing a definition of a Itiird dt^etii, wheran the third dsject includes an added property that is not spedf ied 
in the dass; 

performing the fdlowtng steps subsequent to the conpiiing steps, above: 
using the definition of a first object to create a first object; 
using the definition of a second otjject to aeate a second ot^ed; 
using the definition of a third objed to create a third objed; 
associating the third objed with the second ot^ed; 

executing instructions in a first application to access the first objed and transfer information about the first 
objecfs dass properties to the first application; 

executing instructions in the first aplication to access the second objed and transfer infomnatlon about the sec- 
ond object's dass properties to the first application; and 

efxecuting instructions in a second application to access the second objed and transfer information about the 
added property of the third objed assodated with the second objed to the second application. 

2. The method according to claim 1 , furtfier comprising tiie steps of: 
remo^ng the association between tiie third objed and the second objed; and 

in response to the step of executing instrudions in a second application, indicating to the second application 
20 tiiat tiie added property is not available in association with the second object 

3. The method according to claim 1 or 2, further comprising the steps of: 

modifying the added property: and 
25 sut>sequent to the step of modifying the added property, and in response to the step of executing insfaructions 

in a second application, providing information to ttie second application about the modifications to the added 
property. 

4. The method according to one of claims 1 to 3, wherein a plurality of objects is assodated with the third object so 
30 that any of the plurality of objects, when accessed by tiie second application, return information about tiie added 

property. 

5. The method according to one of claims 1 to 4, wherein the computer system indudes functionality of another cur- 
rently used system, espedally funtionatity specified in the objed linking and embedding (OLE) system of Microsoft, 

S5 Corp.. the method further comprising the Steps of: 

creating a type library that includes information about tiie objects and the properties of the otijeds; and 
wherein the step of associating the third objed with the first objed does not cause the type Ibrnry to be mod- 

40 (fied. 

6. The metiiod according to one of claims 1 to 5, wherein the computer system indudes functionality of another cur- 
rentiy used system, espedally funtionality specified in the objed linking and embedding (OLE) system of Microsoft, 
Corp.. the metiiod further comprising the steps of: 

46 

creating a type library that includes information about the objects and the properties of the objects; and 

wherein the step of assodating tiie third objed witii the second objed does not cause the type library to be 
modified. 

so 

7. The metiiod according to one of daims 1 to 6, wherein the added property is data. 

8. The method according to one of daims 1 to 6 , wherein the added property is a function. 

55 
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